side_diff: fix the column layout overflow and --expand-tabs - #270

`Config::new` sized the side-by-side columns with signed arithmetic on
the `--tabsize` value, which `params.rs` accepts with no upper bound.
`tab_size + GUTTER_WIDTH_MIN` overflowed for a large one: with
`-C overflow-checks=on` that aborted, and in release it wrapped and drew
bogus widths. A value above `isize::MAX` did not even abort, it cast to a
negative number and silently laid the columns out as if the tab size were
small. Closes uutils#264.

The calculation moves into `Config::layout`, in `usize` throughout, and
holds for every input on its own rather than relying on validation
upstream:

- An early return for `tab_size > full_width`. This is exact, not a
  clamp: the offset is a multiple of `tab_size`, so it is either zero or
  already past the right edge, and neither leaves room for a second
  column. It is also what keeps the sum below in range.
- `saturating_add` for the gutter sum, which covers the one case the
  strict `>` lets through, `full_width == tab_size == usize::MAX`.
- `saturating_sub` for the two bounds that could go negative.
  `full_width = 5, tab_size = 8` really does produce an offset past the
  right edge.
- `usize::midpoint` for the balance point, which cannot overflow.
- `saturating_sub` on `separator_pos`, which underflowed for a zero
  width. Unreachable from the CLI, reachable through the library.

A tab stop every zero columns has no meaning and every reader of
`tab_size` divides by it, so `Config::new` now normalizes it to one. The
layout alone was not enough: fixing it only moved the division by zero
from `layout` to `format_tabs_and_spaces`.

The new `mod layout` covers the boundaries, including the two that pin
the design down: `full_width = 10, tab_size = 8` still leaves two
columns, so no looser guard is correct, and `tab_size == full_width`
yields a non-zero offset with an empty half line.

`Config::new` took `expanded` but ignored it when sizing the columns. The
manual's "Preserving Tab Stop Alignment" section explains why it matters:
column two has to start on a tab stop only so that tabs in the right
column keep their position relative to the stops. With `--expand-tabs`
there are no tabs left in the output, so there is no grid to preserve and
every column is a stop.

Compared against the output of `diff` from GNU diffutils 3.10. The
separator column now matches it for `-y -t` at widths 40, 80 and 130, and
for `-y -t --tabsize=4 --width=100`: columns 19, 39, 64 and 49. At the
default width it sat on column 62 before, two columns off.

The tab size still decides how far an expanded tab reaches, so it stays in
the field and only `layout` sees the 1. Feeding the 1 into the field would
shrink every expanded tab to a single space.

The widened half line makes a crash reachable. A tab size near
`usize::MAX` used to yield an empty half line, so `process_half_line`
returned before drawing anything; with `-t` the line now fits and three
expressions of the form
`current_width + tab_size - (current_width % tab_size)` overflowed.
`format_tabs_and_spaces` and the tab arm now measure the step to the next
stop against the room that is left instead of summing absolute columns,
which the surrounding `current_width <= max_width` already bounds.

`test_full_width_40_tab_8` used `expanded = true` and expected the widths
computed while ignoring it. The separator lands on column 19 either way,
so only the half width and the offset change.

The new tests were checked by mutation. Dropping the ternary breaks
`expanded_tabs_widen_the_half_line`,
`expanded_tabs_lay_out_as_a_stop_on_every_column` and
`test_full_width_40_tab_8`; applying it to the field instead breaks
`expanded_tabs_keep_the_real_tab_size_for_rendering` and
`expanded_tabs_reach_the_next_real_tab_stop`.

`width` and `tabsize` were commented out of `fuzz_side`, along with a
`width == 0 || tabsize == 0` early return that was commented out too,
because the column arithmetic could not take arbitrary values. It can
now, so both are fed to the target and neither guard is needed.

They are `u16` rather than `usize`: the layout handles the whole range,
but a width near `usize::MAX` asks the renderer for petabytes of
padding, which would only produce timeouts.

A carriage return pads all the way to column two, the only caller that
reaches the far end of the line. That walk used to add absolute columns
and overflowed with `--width` and `--tabsize` at the top of the range,
which aborts under `-C overflow-checks=on`.

Both values sit at the maximum on purpose: a smaller tab size walks to
that end one stop at a time, and a smaller width never reaches the sum
that overflowed. Expansion stays off, since it pads with spaces one
column at a time and would not finish at this width.

Superscript digits do not survive every terminal or editor the file gets
read in.